Structured document bounding language

ABSTRACT

Methods, systems, computer program products, and methods of doing business by using a bounding language to control or restrict the changes that can be made to contents of a structured document (e.g., a document encoded in the Extensible Markup Language, or “XML”), and also includes the bounding language and documents encoded according to the bounding language. A Document Type Definition (“DTD”) is defined as a “bounding DTD”, and one or more structured documents containing editing restrictions are defined according to this DTD. A processing component uses a structured document containing editing restrictions as input, and programmatically determines which fields of another structured document can be edited, which fields should be hidden, and so forth. By restricting the parts of the file that can be edited, users who need to do the editing are shielded from irrelevant details, and can carry out their task with less risk of making errors (and without needing to understand the details of the structured document markup language).

BACKGROUND OF THE INVENTION

[0001] 1. Related Invention

[0002] The present invention is related to commonly-assigned U.S. Pat.No. ______ (Ser. No. ______), titled “Meta Editor for StructuredDocuments”, which was filed concurrently herewith and is herebyincorporated herein by reference.

[0003] 2. Field of the Invention

[0004] The present invention relates to computer software, and dealsmore particularly with methods, systems, computer program products, andmethods of doing business by using a bounding language to control orrestrict the changes that can be made to contents of a structureddocument (e.g., a document encoded in the Extensible Markup Language, or“XML”), and also includes the bounding language and documents encodedaccording to the bounding language.

RESERVATION OF COPYRIGHT

[0005] A portion of the disclosure of this patent document containsmaterial to which a claim of copyright protection is made. The copyrightowner has no objection to the facsimile reproduction by anyone of thepatent document or the patent disclosure, as it appears in the Patentand Trademark Office patent file or records, but reserves all otherrights whatsoever.

DESCRIPTION OF THE RELATED ART

[0006] XML is a derivative of the Standard Generalized Markup Language,or “SGML”, and is considered the primary publishing language of the Web.XML is a simplified version of SGML, tailored to structured Web documentcontent. XML is an “extensible” markup language in that it providesusers the capability to define their own tags. This makes XML a verypowerful language that enables users to easily define a data model,which may change from one document to another. When an applicationgenerates the XML markup tags (and corresponding data) for a documentaccording to a particular XML data model and transmits that document toanother application that also understands this data model, the XMLnotation functions as a conduit, enabling a smooth transfer ofinformation from one application to the other. By parsing the tags ofthe data model from the received document, the receiving application canre-create the information for display, printing, or other processing, asthe generating application intended it.

[0007] A Document Type Definition (“DTD”) defines the structure of adocument encoded in SGML, or in its derivatives such as XML. (For easeof reference, subsequent discussions herein refer to the XML notation inparticular. However, this is for purposes of illustration and not oflimitation. The discussions herein may be applied also to otherstructured markup languages that use DTDs or similar mechanisms forvalidation.) An XML parser processes an XML DTD along with a documentencoded in XML to validate the document (e.g., to ensure that thedocument adheres to the data model defined by the DTD).

[0008] Because of its power and flexibility, XML is used in many diverseways. While the term “document” is used herein when discussing encodingsof XML, it is to be understood that the information represented usingXML may comprise any type of information, and is not limited to thetraditional interpretation of the word “document”. For example, XML maybe used to represent the layout of records in a data repository, thelayout of a user interface for an application program, or the data to beused with a program or to be used as the values of records in arepository. For ease of reference, the term “document” (or simply “XMLfile”) will be used herein to refer to these diverse types ofinformation.

[0009] One of the many ways in which XML may be used is to specifyconfiguration parameters and configuration data to be used by anexecuting application. In such scenarios, it may be necessary for ahuman user (such as a systems administrator) to edit an XML document,for example to customize the document for a particular installation.This customization might include providing information for initiallysetting up the proper execution environment, or specifying informationpertaining to the setting of user preferences or otherenterprise-specific customization, and so forth. For example, to set upthe execution environment, it might be necessary to provide various pathnames and/or file names at one or more locations within an XML documentthat has been provided for use with an application. As an example ofsetting user preferences by editing an XML document, the document mightcontain syntax for setting the background or text color of graphicaluser interface (“GUI”) panels; the user might then edit the XML documentto specify a particular color. An enterprise-specific customizationmight include editing an XML document to specify the name and/orlocation of a graphic image (such as a company logo) that thisenterprise wishes to display on its GUI panels.

[0010] Many more examples of customizing an XML document by editing itscontents may be imagined. Furthermore, there may be other motivationsfor editing XML documents and for restricting the edits (e.g., due tosecurity concerns), and the references herein to customization shouldtherefore be viewed as illustrative but not as limiting the presentinvention.

[0011] Often, the file that a user is asked to edit contains many moreXML tags (and much more data) than he needs to be exposed to. Forexample, the XML file that a user must edit may be defined by anindustry standard DTD that might have dozens of tags and tag attributes.In such a case, the user may only need to edit a very small portion ofthe file, but is exposed to many details that don't concern him.Sometimes, the user can put the application in an unstable state byediting the XML file incorrectly.

[0012] There are several ways that are currently available for someoneto edit XML. Three of the most common are: (1) using any ASCII texteditor; (2) using one of the many GUI editors that support XML markuptags; (3) or using a customized GUI program provided especially forediting a particular XML file (or files).

[0013] Using an ASCII editor gives the average user no benefit: if theuser is not experienced with XML, he is very likely to be confused ormake mistakes. Accidentally deleting a character from the tag syntax,for example, will make the file invalid, and the inexperienced user mayhave difficulty in correcting simple problems of this type.

[0014] There are several GUI editors on the market that support XMLmarkup tags, but these generally do not provide users with much morebenefit than the ASCII editors. That is, the user is still required tounderstand XML in order to avoid making mistakes—although the GUI editormay make it easier to locate and correct simple mistakes, through itsknowledge of valid XML syntax.

[0015] In both the ASCII and GUI XML editor scenarios, the fact remainsthat the user is exposed to the entire file being edited, even though hemay only be concerned with a fraction of the data. This may addsignificantly to the user's confusion and the possibility for makingmistakes. Furthermore, there may be parts of the data that the usershould not be changing, and the ASCII and GUI XML editor scenarios arenot able to provide “selective” file editing capability.

[0016] A customized GUI program provided especially for editing aparticular XML file is the best way for a user to edit XML; however, itcan be extremely expensive for an application development team toprovide such a customized program that will meet the needs of a diverseset of users.

[0017] Accordingly, what is needed is a cost-effective way to enableusers to edit XML files (or files encoded in other markup languages),while shielding them from details of the XML language (e.g., the tagsand attributes of a particular data model) and at the same time,enabling application developers to have some control over what the userscan do when they are editing XML files.

SUMMARY OF THE INVENTION

[0018] An object of the present invention is to provide cost-effectivetechniques to enable users to edit structured document files, such asXML files.

[0019] Another object of the present invention is to provide thesetechniques in a manner that shields users from details of the markuplanguage used for encoding the structured document file.

[0020] Yet another object of the present invention is to providetechniques that enable application developers to have some control overwhat users can do when editing a structured document file.

[0021] A further object of the present invention is to providetechniques for using a bounding language to restrict the changes thatcan be made to contents of a structured document.

[0022] Other objects and advantages of the present invention will be setforth in part in the description and in the drawings which follow and,in part, will be obvious from the description or may be learned bypractice of the invention.

[0023] To achieve the foregoing objects, and in accordance with thepurpose of the invention as broadly described herein, the presentinvention provides software-implemented methods, systems, and computerprogram products for controlling manipulation of contents of astructured document. In preferred embodiments, this technique comprises:processing a bounding file to determine restrictions on how a structureddocument can be manipulated, wherein the bounding file adheres to abounding language that is defined according to a second structuredmarkup language definition document that specifies allowablerestrictions on how contents of the structured document can bemanipulated, wherein the structured document is defined according to afirst structured markup language definition document; and enforcing thedetermined restrictions on how the structured document can bemanipulated.

[0024] Typically, the first structured markup language definitiondocument and the second structured markup language definition documentare DTD documents, and the structured document is encoded in XML.

[0025] The bounding file may specify (for example) one or more elementsof the structured document that can be edited and/or one or moreelements that should be hidden from editing. It may alternatively oradditionally specify (for example) one or more parameters of one or moreelements of the structured document that can be edited and/or one ormore parameters of one or more elements of the structured document thatshould be hidden from editing.

[0026] Enforcing the restrictions preferably further comprises editing,by a user, the structured document; and automatically constraining theediting according to the determined restrictions.

[0027] In another embodiment, the present invention provides one or morebounding documents encoded in a structured markup language, wherein aparticular bounding document may be stored on one or morecomputer-readable media and comprises one or more restrictions on how astructured document can be edited. The one or more restrictions areencoded in the structured markup language, and adhere to a boundinglanguage that is defined according to a bounding language definitiondocument (e.g., a bounding DTD) that specifies allowable restrictions onhow contents of the structured document can be manipulated, and thestructured document is defined according to a structured markup languagedefinition document (e.g., an XML DTD). The one or more restrictionspreferably refer to markup language elements defined in the structuredmarkup language definition document.

[0028] The disclosed techniques may also be used advantageously inmethods of doing business, whereby a service is offered to clients for(1) providing one or more XML bounding files to control changes to bemade when users edit selected files and/or (2) deploying an editingcapability that enforces such controls. This service may be providedunder various revenue models, such as pay-per-use billing, monthly orother periodic billing, and so forth, and may offer clients advantagesof improved accuracy for XML file editing and reduced debugging timecaused by inaccurate editing.

[0029] The present invention will now be described with reference to thefollowing drawings, in which like reference numbers denote the sameelement throughout.

BRIEF DESCRIPTION OF THE DRAWINGS

[0030]FIG. 1 is a block diagram of a computer workstation environment inwhich the present invention may be practiced;

[0031]FIG. 2 is a diagram of a networked computing environment in whichthe present invention may be practiced;

[0032]FIG. 3 illustrates, at a high level, components used in preferredembodiments of the present invention;

[0033]FIG. 4 shows a sample XML file that users might need to edit,where the editing can be advantageously controlled using techniquesdisclosed herein;

[0034]FIG. 5 shows a “bounding DTD” that defines allowable syntax forspecifying “bounds” on how files such as the sample XML file in FIG. 4can be edited;

[0035]FIG. 6 depicts a sample “XML bounding file” that adheres to thebounding DTD in FIG. 5, and which specifies a particular set ofrestrictions or bounds on editing a file such as the sample XML file inFIG. 4;

[0036]FIG. 7 provides a flow chart that sets forth logic which may beused to implement preferred embodiments of the present invention;

[0037]FIG. 8 provides an alternative bounding DTD, which may be used inalternative embodiments to provide different degrees of control whenspecifying bounds on how files such as the sample XML file in FIG. 4 canbe edited; and

[0038]FIG. 9 illustrates a sample XML bounding file created according tothe alternative bounding DTD in FIG. 8.

DESCRIPTION OF PREFERRED EMBODIMENTS

[0039]FIG. 1 illustrates a representative workstation hardwareenvironment in which the present invention may be practiced. Theenvironment of FIG. 1 comprises a representative single user computerworkstation 10, such as a personal computer, including relatedperipheral devices. The workstation 10 includes a microprocessor 12 anda bus 14 employed to connect and enable communication between themicroprocessor 12 and the components of the workstation 10 in accordancewith known techniques. The workstation 10 typically includes a userinterface adapter 16, which connects the microprocessor 12 via the bus14 to one or more interface devices, such as a keyboard 18, mouse 20,and/or other interface devices 22, which can be any user interfacedevice, such as a touch sensitive screen, digitized entry pad, etc. Thebus 14 also connects a display device 24, such as an LCD screen ormonitor, to the microprocessor 12 via a display adapter 26. The bus 14also connects the microprocessor 12 to memory 28 and long-term storage30 which can include a hard drive, diskette drive, tape drive, etc.

[0040] The workstation 10 may communicate with other computers ornetworks of computers, for example via a communications channel or modem32. Alternatively, the workstation 10 may communicate using a wirelessinterface at 32, such as a cellular digital packet data (“CDPD”) card.The workstation 10 may be associated with such other computers in alocal area network (“LAN”) or a wide area network (“WAN”), or theworkstation 10 can be a client in a client/server arrangement withanother computer, etc. All of these configurations, as well as theappropriate communications hardware and software, are known in the art.

[0041]FIG. 2 illustrates a data processing network 40 in which thepresent invention may be practiced. The data processing network 40 mayinclude a plurality of individual networks, such as wireless network 42and network 44, each of which may include a plurality of individualworkstations 10. Additionally, as those skilled in the art willappreciate, one or more LANs may be included (not shown), where a LANmay comprise a plurality of intelligent workstations coupled to a hostprocessor.

[0042] Still referring to FIG. 2, the networks 42 and 44 may alsoinclude mainframe computers or servers, such as a gateway computer 46 orapplication server 47 (which may access a data repository 48). A gatewaycomputer 46 serves as a point of entry into each network 44. The gateway46 may be preferably coupled to another network 42 by means of acommunications link 50 a. The gateway 46 may also be directly coupled toone or more workstations 10 using a communications link 50 b, 50 c. Thegateway computer 46 may be implemented utilizing an Enterprise SystemsArchitecture/370™ available from the International Business MachinesCorporation (“IBM®”), an Enterprise Systems Architecture/390® computer,etc. Depending on the application, a midrange computer, such as anApplication System/400® (also known as an AS/400®) may be employed.(“Enterprise Systems Architecture/370” is a trademark of IBM; “IBM”,“Enterprise Systems Architecture/390”, “Application System/400”, and“AS/400” are registered trademarks of IBM.)

[0043] The gateway computer 46 may also be coupled 49 to a storagedevice (such as data repository 48). Further, the gateway 46 may bedirectly or indirectly coupled to one or more workstations 10.

[0044] Those skilled in the art will appreciate that the gatewaycomputer 46 may be located a great geographic distance from the network42, and similarly, the workstations 10 may be located a substantialdistance from the networks 42 and 44. For example, the network 42 may belocated in California, while the gateway 46 may be located in Texas, andone or more of the workstations 10 may be located in Florida. Theworkstations 10 may connect to the wireless network 42 using anetworking protocol such as the Transmission Control Protocol/InternetProtocol (“TCP/IP”) over a number of alternative connection media, suchas cellular phone, radio frequency networks, satellite networks, etc.The wireless network 42 preferably connects to the gateway 46 using anetwork connection 50 a such as TCP or User Datagram Protocol (“UDP”)over IP, X0.25, Frame Relay, Integrated Services Digital Network(“ISDN”), Public Switched Telephone Network (“PSTN”), etc. Theworkstations 10 may alternatively connect directly to the gateway 46using dial connections 50 b or 50 c. Further, the wireless network 42and network 44 may connect to one or more other networks (not shown), inan analogous manner to that depicted in FIG. 2.

[0045] Software programming code which embodies the present invention istypically accessed by the microprocessor 12 of the workstation 10 orserver 47 from long-term storage media 30 of some type, such as a CD-ROMdrive or hard drive. The software programming code may be embodied onany of a variety of known media for use with a data processing system,such as a diskette, hard drive, or CD-ROM. The code may be distributedon such media, or may be distributed from the memory or storage of onecomputer system over a network of some type to other computer systemsfor use by such other systems (and their users). Alternatively, theprogramming code may be embodied in the memory 28, and accessed by themicroprocessor 12 using the bus 14. The techniques and methods forembodying software programming code in memory, on physical media, and/ordistributing software code via networks are well known and will not befurther discussed herein.

[0046] The computing environment in which the present invention may beused includes an Internet environment, an intranet environment, anextranet environment, or any other type of networking environment. Theseenvironments may be structured in various ways, including aclient-server architecture or a multi-tiered architecture. The presentinvention may also be used in a disconnected (i.e. stand-alone) mode,for example where a user edits an XML file on a workstation, server, orother computing device without communicating across a computing network.

[0047] When used in a networking environment, a user of the presentinvention may connect his computer to a server using a wirelineconnection or a wireless connection. Wireline connections are those thatuse physical media such as cables and telephone lines, whereas wirelessconnections use media such as satellite links, radio frequency waves,and infrared waves. Many connection techniques can be used with thesevarious media, such as: using the computer's modem to establish aconnection over a telephone line; using a LAN card such as Token Ring orEthernet; using a cellular modem to establish a wireless connection;etc. The user's computer may be any type of computer processor,including laptop, handheld, or mobile computers; vehicle-mounteddevices; desktop computers; mainframe computers; personal digitalassistants (“PDAs”); Web-enabled cellular phones; Web appliances;wearable computing devices; so-called “smart” appliances in the home;etc., having processing (and optionally communication) capabilities. Theremote server, similarly, can be one of any number of different types ofcomputer which have processing and communication capabilities. Thesetechniques are well known in the art, and the hardware devices andsoftware which enable their use are readily available. Hereinafter, theuser's computer will be referred to equivalently as a “workstation”,“device”, or “computer”, and use of any of these terms or the term“server” refers to any of the types of computing devices describedabove.

[0048] In the preferred embodiment, the present invention is implementedas one or more computer software programs. The software may operate on aserver in a network, as one or more modules (also referred to as codesubroutines, or “objects” in object-oriented programming) which areinvoked upon request. Alternatively, the software may operate on auser's workstation. The server may be functioning as a Web server, wherethat Web server provides services in response to requests from a clientconnected through the Internet. Alternatively, the server may be in acorporate intranet or extranet of which the client's workstation is acomponent, or in any other networking environment.

[0049] The present invention enables application developers to use theirdomain-specific or application-specific knowledge to bound user actionswhen users are editing XML files. A bounding DTD is defined, and one ormore bounding files may be created according to this bounding DTD, whereeach bounding file specifies a particular set of restrictions on editingan XML file. A bounding DTD correlates to the DTD for an XML file thatrequires customization (i.e., editing). This bounding DTD containselements that describe actions to take against defined elements of anXML file created according to the other DTD. These actions can include,but need not be limited to, “hide the element” (either hide the entireelement or hide specified child elements); “make the elementnon-editable” (either the entire element is non-editable or specifiedchild elements are non-editable); etc.

[0050] For example, a bounding file might specify that certain tags(including their data and the data of their child tags) are nevereditable, while another bounding file might specify that tags arenon-editable only under certain conditions (such as the tag's attributeshaving particular values). The bounding files are also encoded in XML,in preferred embodiments, and are referred to equivalently herein as“XML bounding files”. (The term “XML element” is used herein to refer toan XML tag and its data.)

[0051] After the bounding DTD is completed, an XML bounding file can bewritten (for example, by a product development team) under therestrictions of the bounding DTD. A processing component (which, inpreferred embodiments, operates within an editing component) then readsin this XML bounding file and, based on its specified restrictions,provides a set of editing actions that limit the user in what he can seeand do with an XML element. This XML bounding file can then be changed,if desired, so that the processing component acts differently, dependingon the revised restrictions in the XML bounding file. Thus, editingoperations available in the same processing component (and on the sameinput XML file for which editing is to be bounded) can be tailored todifferent users with diverse needs or different tasks as long as thereis a different implementation of the XML bounding file.

[0052] As stated earlier, the techniques disclosed herein enablecontrolling how users edit structured documents. Preferred embodimentswill be described with reference to editing files that containinformation for setting up an application execution environment.However, it should be apparent that editing files (and restrictingedits) for other motivations and editing other types of files are alsowithin the scope of the present invention.

[0053] Note that the word “file” is used in this disclosure to refer tostored data. This is for ease of reference only, and is not meant toimply any particular structure for storing the data, such as 5conventional “flat files”. The data with which the present invention maybe beneficially used may be stored in any number of ways withoutdeviating from the inventive concepts disclosed herein, such as: a dataelement in a database, an object attribute in a directory entry, anobject in flash memory, etc.

[0054] Techniques are known in the art with which GUI editors allow XMLfiles created according to a DTD to be edited (and validated). The Xeenaeditor, for example, parses a DTD to learn the syntax of documentsadhering to that DTD, and then builds this knowledge into a visual,tree-directed editing paradigm where users are not allowed to defineinvalid XML files. Thus, if the DTD specifies allowable tags as <A>,<B>, and <C>, the user is not allowed to create a file with a tag <D>.The present invention, on the other hand, provides much finer-grainedcontrol over the editing process, using one DTD that correlates toanother DTD, as will be described.

[0055] Preferred embodiments of the present invention will now bediscussed in more detail with reference to FIGS. 3-9.

[0056]FIG. 3 illustrates components used in preferred embodiments. Afirst DTD 300 and a first XML document 310 are provided, where XMLdocument/file 310 adheres to the syntax requirements specified in DTD300. As is known in the art, a DTD defines allowable syntax, anddocuments may then be written that adhere or conform to this syntax orlanguage. Arrow 305 is intended to show this relationship between DTD300 and XML document 310. Assume for purposes of discussion that XMLdocument 310 is quite large, having perhaps hundreds of elements (someof which may obviously use the same tags). Problems encountered in theprior art when users are expected to edit a file of this type withoutcompromising its syntactic and semantic integrity have been describedabove.

[0057] The present invention defines a bounding DTD 320. This boundingDTD is directed toward limiting the changes that can be made to XMLdocument 310. Arrow 315 therefore denotes a relationship between DTD 300and bounding DTD 320. The bounding DTD defines the allowable syntax foran XML bounding file. Arrow 325 shows this relationship between abounding DTD and its XML bounding file(s). Just as more than one XML maybe created that adheres to the syntax requirements specified in DTD 300,more than one XML bounding file may be created according to the boundingDTD. FIG. 3 illustrates a first XML bounding file 330 and second XMLbounding file 331. (Note that embodiments of the present invention neednot include, or process, more than one XML bounding file for bounding aparticular XML file; two XML bounding files 330, 331 are shown in FIG. 3for purposes of illustration.)

[0058] A bounding file may be considered as embodying a set of rules,where these rules conform to the bounding DTD and specify how a documentinstance (such as XML document 310) created according to a different DTD(such as DTD 300) can be edited. Arrow 335 indicates that XML boundingfiles 330, 331 are related to XML document 310 in this manner.

[0059] A particular XML bounding file 330 is input to a processingcomponent 340, according to the present invention. The processingcomponent 340 processes the XML bounding file to control the editing ofanother XML file 310. Processing component 340 therefore has arelationship, indicated by arrow 345, to the XML file 310 (or, moreprecisely, to a revised version of XML file 310 that is created by theuser as he uses processing component 340 for editing; thus arrow 345indicates that the XML document 310 may be an input as well as an outputof processing component 340). The bounding DTD may also be used as aninput to processing component 340, for example to validate the syntax ofthe XML bounding file.

[0060] So, for example, if XML document 310 does in fact have hundredsof elements, using dozens of different tags, there may be scenarios inwhich the users should only be allowed to change some very small numberof these elements. These restrictions are specified, according to thepresent invention, in an XML bounding file 330. Processing component 340will therefore only allow the user to access this very small number ofidentified elements.

[0061] A more detailed example of files used by an embodiment of thepresent invention will be described with reference to the sample filesin FIGS. 4-6. FIG. 4 is a simple example of an XML file to be edited.This particular example file adheres to the defacto standard DTD definedby Sun Microsystems, Inc., for Web applications. This DTD has not beenreproduced herein, because it is to be used under license for servletdeployment, but its contents may be viewed on the Internet at thelocation shown by reference number 405. (The particular contents of thisDTD are not material to an understanding of the present invention.Sample file 400 represents an accurate subset of the language definedtherein.)

[0062] In the sample XML file 400, 4 servlet elements 410, 420, 430, 440are defined. By referring to the description (sub)elements (i.e., thevalues of the <description> tags), it can be seen that these servletsare for HTTPProxy Mib service requests, HTTPProxy SNMP service requests,security checking, and servicing browser requests for z/NetViewfunction, respectively. Further details of these servlet elements willbe discussed with reference to FIGS. 5 and 6. (The syntax in FIG. 4 hasbeen extracted from a file named “web.xml” that ships with IBM's Tivoli®NetView® for z/OS™ product, where this file is used for establishing theenvironment thereof. For the sake of brevity, only representative syntaxelements have been included herein, and therefore this sample file 400is not intended to provide complete details for environmentestablishment. “Tivoli” and “NetView” are registered trademarks, and“z/OS” is a trademark, of IBM.)

[0063] A bounding DTD 500 is shown in FIG. 5. This bounding DTDspecifies allowable syntax for creating a sample XML bounding file suchas bounding file 600 in FIG. 6. The syntax of DTD 500 will be readilyunderstandable to one of ordinary skill in the art. In particular, thisDTD defines a language that has a “bounds” element as the root, wherethis bounds element optionally has a “non-editable” child element and a“hidden” child element. Each of these child elements may contain one ormore “servlet” child elements. A servlet element optionally has a“servlet-name-field”, “display-name-fieid”, “description-field”,“class-jsp-field”, and a “load-on-startup-field” element, according tothe syntax at 510. In this example, no tags have attributes except forthe servlet tag, which requires an “id” attribute, as shown at 520.

[0064] According to techniques disclosed herein, an XML boundinglanguage (such as that represented in DTD 500 of FIG. 5) can helpdevelopers easily control how users are allowed to manipulate XML data,in a very cost-effective manner. The developers simply prepare an XMLbounding file (such as that represented at 600 in FIG. 6) that sets outrules, according to the bounding DTD syntax, for the data editing. Aprocessing component then enforces these rules (as will be described inmore detail with reference to FIG. 7). If the developers decide, at somepoint, that it would be desirable to control the manipulations in someother manner, or perhaps that they would like a different set ofcontrols for a different user audience (for example, an audience thatneeds to perform different tasks with the XML file being bounded), thedevelopers merely prepare a different XML bounding file and use this asinput to the processing component. The editing restrictions cantherefore be changed by the developers in an easily-modifiable way, andthe editing restrictions can be adapted for use by diverse sets ofusers, each of which have slightly different needs, all withoutrequiring re-compiling code.

[0065] Referring now to FIG. 6, this XML bounding file 600 includes areference 605 to the bounding DTD in FIG. 5, a <non-editable> element610, and a <hidden> element 640. Two servlets are identified as havingfields that are non-editable, using <servlet> elements 620, 630, andanother is specified as having fields that are hidden using <servlet>element 650. In particular, the element 620 and its tags 622, 623specify that, if a servlet having an identifier matching the IDattribute value specified at 621 is located in the XML file to bebounded, then the processing component is to prevent the user fromediting the <servlet-name> field and the <load-on-startup> fields inthis servlet. The restrictions on the servlet identified in element 630are identical. Note that the tags 622, 623 have been selected by thedeveloper, in view of his knowledge of the contents of XML file 400 ofFIG. 4, from the possible choices identified at 510 in the bounding DTD.In the case of the <hidden> element 640, tags for all five of theallowable child elements have been specified, and thus when a servlethaving the identifier at 651 appears in the XML file 400, the processingcomponent will ensure that all five of its fields will be hidden fromthe user during the editing process.

[0066] The manner in which the processing component enforces therestrictions in the XML bounding file will now be described withreference to FIG. 7. The logic depicted therein may be used to processan XML file to be bounded, by analyzing each of the <servlet> elementsin that XML file in view of the restrictions specified by the XMLbounding file. (Note that if the bounding DTD in a particularimplementation allows additional or different tag names, then it will beobvious to one of ordinary skill in the art how the logic in FIG. 7 maybe adapted for processing these additional or different names.)

[0067] Block 700 therefore obtains the next <servlet> element from theinput XML file (i.e., the file to be bounded, which is also the file tobe edited). Block 705 checks to see if the input file is at the end. Ifso, then the user is allowed to edit the input XML file (using asuitable GUI or other interface), as shown at Block 795, according tothe restrictions that have been programmatically determined whileiterating through the logic of FIG. 7. If there are still more <servlet>elements to analyze in the input XML file, then processing continues atBlock 710. Blocks 710-790 compare the current <servlet> element to therestrictions (which, in the example, are specified at 620, 630, 650) ofthe XML bounding file, and thereby determine whether fields of thiscurrent element should be editable or hidden.

[0068] Block 710 checks to see if this <servlet> element matches anentry in the “hidden” section of the XML bounding file. In preferredembodiments, this comprises comparing the value of the current servlettag's ID attribute to the value specified in the <servlet> tags withinthe <hidden> element 640. If not, then control transfers to Block 750 tobegin evaluating the current <servlet> tag with reference to the“non-editable” section of the XML bounding file. Otherwise, when thecurrent servlet is specified in the hidden section, then Block 715 getsthe next field (i.e., the next tag, specifying a particular field to behidden) from the servlet's element within the input XML file. Block 720checks to see if the list of fields is at the end. If so, then controltransfers to Block 750, and if not, processing continues at Block 725,where a test is made to see if this current field from the input XMLfile is specified in the servlet's tag within the XML bounding file(indicating that the field is to be hidden).

[0069] With reference to the examples, suppose <servlet> element 410from FIG. 4 is being analyzed. The ID attribute value of this servletelement does not match any of the attribute values within <hidden>element 640, and thus the test at Block 710 has a negative result whenprocessing this servlet element, transferring control directly to Block750.

[0070] If this field is to be hidden (i.e., the test in Block 725 has apositive result), then at Block 730, provision is made for notdisplaying this field to the user for editing. (This may be accomplishedin a number of ways, such as setting a binary flag that the processingcomponent associates with this tag from the input XML file; storinginformation in a data structure, such as a composite list of editablefields; etc. Hereinafter, such provisions are referred to as “marking”the field.) Control then returns to Block 715 to get the next field fromthe input XML file.

[0071] When the test in Block 725 has a negative result, then this fieldcan be displayed to the user, and thus Block 735 marks the field to thiseffect before returning control to Block 715.

[0072] Block 750 is reached when the current <servlet> tag from theinput XML file has been fully analyzed with reference to the <hidden>element of the XML bounding file, and begins the analysis of thiscurrent tag with reference to the <non-editable> element, Block 750therefore checks to see if this current <servlet> element matches anentry in the “non-editable” section of the XML bounding file. Inpreferred embodiments, this comprises comparing the value of the currentservlet tag's ID attribute to the value specified in the <servlet> tagswithin the <non-editable> element 640. (Note that the logic in FIG. 7allows a particular servlet from the input XML file to have some fieldsthat are hidden and some fields that are non-editable.) If this servletis not identified in the non-editable section (i.e, the test in Block750 has a negative result), then analysis of this current servletelement is complete and control transfers to Block 790.

[0073] Referring again to the examples, because the ID attribute of<servlet> element 410 matches one of the attribute values within<non-editable> element 610 (in particular, the value in element 630),the test at Block 750 has a positive result when processing this servletelement, and the fields of <servlet> element 410 will therefore beanalyzed by transferring control to Block 755.

[0074] Otherwise, when the current servlet is specified in thenon-editable section (i.e, the test in Block 750 has a positive result),then Block 755 gets the next field (which in this case specifies aparticular field as being non-editable) from the servlet's elementwithin the input XML file. Block 760 checks to see if the list of fieldsis at the end. (Note that the list of servlet fields is processed anewin the logic of Blocks 750-775, and thus each field processed in Blocks710-735 is processed again, using the logic of FIG. 7.) If so, thencontrol transfers to Block 790, and if not, processing continues atBlock 765, where a test is made to see if this current field from theinput XML file is specified in the servlet's tag within the XML boundingfile (indicating that the field is non-editable).

[0075] If this field cannot be edited (i.e., the test in Block 765 has apositive result), then at Block 770, this field of the current servletis marked as non-editable by the processing component. Control thenreturns to Block 755 to get the next field from the input XML file.

[0076] When the test in Block 765 has a negative result, then this fieldcan be edited by the user, and thus Block 775 marks the field to thiseffect before returning control to Block 755.

[0077] With reference to the examples, the first field from the inputXML file for <servlet> element 410 is <servlet-name> 412. Block 765 willdetermine that this field is present in the XML bounding file for thisservlet, and Block 770 will therefore mark the field accordingly. Block755 will then get the <display-name> tag 413, and because this tag isnot listed in the XML bounding file entry at 630, the processing ofBlock 775 will be reached, where this field will be marked as editable.

[0078] Upon reaching Block 790, analysis of this current servlet elementfrom the input XML file, regarding whether the fields of this servletelement are hidden and/or non-editable, is complete. Control thenreturns to Block 700, where the next <servlet> element from the inputXML file will be retrieved for processing. (Referring to the exampleinput XML file 400, <servlet> tag 420 will be processed by the nextiteration through the logic of FIG. 7.)

[0079] Once control reaches Block 795, the XML bounding file has beenapplied to the entire contents of the input XML file, determining howthe user should be allowed to edit the that file. Block 795 thereforeallows the editing to processed, as stated earlier, using a suitable GUIor other interface. This GUI uses the markings created by iteratingthrough FIG. 7, and displays only those fields which are not marked ashidden, and allows editing only of those fields which are not marked asnon-editable.

[0080] In alternative embodiments, the bounding DTD may provideadditional or different types of controls on the user's editingcapabilities. That is, while the bounding DTD in FIG. 5 allows thedeveloper to restrict, on a per-tag level, whether tags in identifiedservlets can be hidden or edited, it may be desirable to offerdevelopers other approaches. Thus, the language defined by the boundingDTD in FIG. 5 is provided by way of illustration, but not of limitation.Once the techniques disclosed herein are known, those of skill in theart may use these techniques for defining other bounding languages andfor creating processing components that enforce the features of theseother bounding languages. FIG. 8 shows one such alternative bounding DTD800, which may be used in alternative embodiments when specifying XMLbounding files to control the editing of input XML files. This boundingDTD 800 will be described with reference to how it differs from boundingDTD 500. FIG. 9 illustrates a sample XML bounding file 900 createdaccording to bounding DTD 800, and will be used to describe elementsthereof.

[0081] As shown at 810, this bounding DTD 800 includes more types ofrestrictions than simply hiding tags and specifying tags as beingnon-editable. Additional choices include a “global” element and an“action-required” element. These elements are shown in one preferredexpanded form at 820 and 850, respectively. Furthermore, the“non-editable” and “hidden” choices have been defined differently, incontrast to bounding DTD 500, and a preferred expansion of theseelements is provided at 830 and 840, respectively.

[0082] The global element 820 may be used as a Boolean flag, where theappearance of one of its child elements in an XML bounding file providesa signal to the processing component for restrictions that are to beapplied to an input XML file in a global manner, without regard toindividual tags or elements. Thus in FIG. 9, the <global> element 900includes two tags that function in this manner. As explained in thecomments within bounding DTD 800, the first of these tags signals theprocessing component that the user is not allowed to add any newservlets to the input XML file, and the second of these tags signals theprocessing component that no new initialization parameters (i.e.,“<init-param>” tags) are to be added. Note that the definition of thissecond tag, “<disable-add-new-init-param>”, provided in bounding DTD 800allows for a child element that names a particular servlet. Thus, thedeveloper may allow for new <init-param> tags to be added for someservlets, but not for others.

[0083] In this bounding DTD 800, the highest-level definition of“<non-editable>” is different from that in bounding DTD 500. Here,provisions are made for specifying tags in the XML bounding file thatwill signal the processing component to make selected fields of allservlets non-editable (using “<non-editable-all-servlet>”, then namingthe selected fields as shown at 920 of FIG. 9); to make selected fieldsof identified servlets non-editable (using “<non-editable-all-servlet>”,then providing a <servlet-name> element along with the selected fieldsas shown at 930 of FIG. 9); to make selected initialization parametersof all servlets non-editable (using “<non-editable-all-init-param>”,then naming the selected fields as shown at 940 of FIG. 9); and to makeselected initialization parameters of identified servlets non-editable(using “<non-editable-init-param>”, then providing a <param-name-field>element along with the selected initialization parameters; this has notbeen illustrated in FIG. 9). Note that these four choices can be appliedto all servlets, all fields of an identified servlet, all initializationparameters, or all initialization parameters of an identified servlet,respectively, by omitting a child element in the XML bounding file.Thus, if the <param-name-field> tag was omitted in element 940, theprocessing component preferably interprets this is a signal to preventediting of all initialization parameters (i.e., of all <init-param>elements).

[0084] The “<non-editable-servlet>” element definition at 830 includesadditional fields, as compared to the “<servlet>” element within the<non-editable> element of the bounding DTD 500 in FIG. 5, including a<servlet-name> element with which servlets are to be identifiedaccording to this particular bounding language and a<servlet-mapping-field> element (which may be processed similarly toother elements).

[0085] The “<hidden>” element definition at 840 allows hiding servletsby name, using syntax such as that shown at 950, as well as hidingidentified <init-param> elements. In the latter case, an identified<init-param> element can be hidden for all servlets by omittingspecification of a <servlet-name> child element in the XML bounding DTD,as shown in FIG. 9 at 960. (In other words, this syntax at 960 specifiesthat no occurrences of the <param-name> element having a value of“ZNV_INSTALLATION” are editable within any <init-param> elements.)

[0086] Bounding DTD 800 provides the developer a way to specify thatcertain actions are required from the editing user, using an<action-required> element defined at 850. This required action maypertain to a named servlet, as shown at 970 in FIG. 9, or to a namedinitialization parameter, as shown at 980. As can be seen by inspectingthe definitions at 850, the developer may specify that action isrequired, in the servlet case, on the <servlet-name-field> tag,<display-name-field> tag, etc.; in the initialization parameter case, hemay specify that action is required on the <servlet-name> tag,<param-name-field> tag, etc.

[0087] Based on the teachings disclosed herein (and with reference tothe example in FIG. 7), logic for handling these additional anddifferent choices may be provided to create a processing component thatenforce the features of this bounding language, in order that an XMLbounding file such as file 900 in FIG. 9 can be used to programmaticallyrestrict editing of input XML files.

[0088] As has been demonstrated, the present invention provides a numberof advantages, including allowing users to have a way to edit an XMLfile without necessarily having any XML knowledge; allowing developersto provide restrictions on the user's editing capabilities by (forexample) specifying selected elements that are to be hidden from theuser and/or that the user is to be prevented from editing; and reducingthe user's risk of error, thereby limiting the possibility of usersmaking their environment unstable. It may be advantageous, in someimplementations, to incorporate the teachings herein into the featuresof a toolkit.

[0089] While preferred embodiments of the present invention have beendescribed, additional variations and modifications in those embodimentsmay occur to those skilled in the art once they learn of the basicinventive concepts. The techniques disclosed herein are based partiallyupon certain predefined characteristics of the notations beingprocessed. It will be obvious to one of ordinary skill in the art thatthe inventive concepts disclosed herein may be adapted to changes in thenotations, should they occur. Furthermore, while preferred embodimentsare described with reference to a DTD, this is intended to encompassanalogous types of structured markup language definition documents.Therefore, it is intended that the appended claims shall be construed toinclude both the preferred embodiments and all such variations andmodifications as fall within the spirit and scope of the invention.

What is claimed is:
 1. A software-implemented method for controllingmanipulation of contents of a structured document, comprising steps of:processing a bounding file to determine restrictions on how a structureddocument can be manipulated, wherein the bounding file adheres to abounding language that is defined according to a second structuredmarkup language definition document that specifies allowablerestrictions on how contents of the structured document can bemanipulated, wherein the structured document is defined according to afirst structured markup language definition document; and enforcing thedetermined restrictions on how the structured document can bemanipulated.
 2. The method according to claim 1, wherein the firststructured markup language definition document and the second structuredmarkup language definition document are Document Type Definition (“DTD”)documents.
 3. The method according to claim 1, wherein the structureddocument is encoded in Extensible Markup Language (“XML”).
 4. The methodaccording to claim 1, wherein the bounding file specifies one or moreelements of the structured document that can be edited.
 5. The methodaccording to claim 1, wherein the bounding file specifies one or moreelements of the structured document that should be hidden from editing.6. The method according to claim 1, wherein the bounding file specifiesone or more parameters of one or more elements of the structureddocument that can be edited.
 7. The method according to claim 1, whereinthe bounding file specifies one or more parameters of one or moreelements of the structured document that should be hidden from editing.8. The method according to claim 1, wherein the enforcing step furthercomprises the steps of: editing, by a user, the structured document; andautomatically constraining the editing according to the determinedrestrictions.
 9. A system for controlling manipulation of contents of astructured document, comprising: means for processing a bounding file todetermine restrictions on how a structured document can be manipulated,wherein the bounding file adheres to a bounding language that is definedaccording to a second structured markup language definition documentthat specifies allowable restrictions on how contents of the structureddocument can be manipulated, wherein the structured document is definedaccording to a first structured markup language definition document; andmeans for enforcing the determined restrictions on how the structureddocument can be manipulated.
 10. The system according to claim 9,wherein the first structured markup language definition document and thesecond structured markup language definition document are Document TypeDefinition (“DTD”) documents.
 11. The system according to claim 9,wherein the structured document is encoded in Extensible Markup Language(“XML”).
 12. The system according to claim 9, wherein the bounding filespecifies one or more elements of the structured document that can beedited.
 13. The system according to claim 9, wherein the bounding filespecifies one or more elements of the structured document that should behidden from editing.
 14. The system according to claim 9, wherein thebounding file specifies one or more parameters of one or more elementsof the structured document that can be edited.
 15. The system accordingto claim 9, wherein the bounding file specifies one or more parametersof one or more elements of the structured document that should be hiddenfrom editing.
 16. The system according to claim 9, wherein the means forenforcing further comprises: means for editing, by a user, thestructured document; and means for automatically constraining theediting according to the determined restrictions.
 17. A computer programproduct for controlling manipulation of contents of a structureddocument, the computer program product embodied on one or morecomputer-readable media and comprising: computer-readable program codemeans for processing a bounding file to determine restrictions on how astructured document can be manipulated, wherein the bounding fileadheres to a bounding language that is defined according to a secondstructured markup language definition document that specifies allowablerestrictions on how contents of the structured document can bemanipulated, wherein the structured document is defined according to afirst structured markup language definition document; andcomputer-readable program code means for enforcing the determinedrestrictions on how the structured document can be manipulated.
 18. Thecomputer program product according to claim 17, wherein the firststructured markup language definition document and the second structuredmarkup language definition document are Document Type Definition (“DTD”)documents.
 19. The computer program product according to claim 17,wherein the structured document is encoded in Extensible Markup Language(“XML”).
 20. The computer program product according to claim 17, whereinthe bounding file specifies one or more elements of the structureddocument that can be edited.
 21. The computer program product accordingto claim 17, wherein the bounding file specifies one or more elements ofthe structured document that should be hidden from editing.
 22. Thecomputer program product according to claim 17, wherein the boundingfile specifies one or more parameters of one or more elements of thestructured document that can be edited.
 23. The computer program productaccording to claim 17, wherein the bounding file specifies one or moreparameters of one or more elements of the structured document thatshould be hidden from editing.
 24. The computer program productaccording to claim 17, wherein the computer-readable program code meansfor enforcing further comprises: computer-readable program code meansfor editing, by a user, the structured document; and computer-readableprogram code means for automatically constraining the editing accordingto the determined restrictions.
 25. A method of providing restrictionson how users can edit structured documents, comprising steps of:providing a bounding file that specifies restrictions on how astructured document can be edited, wherein the bounding file adheres toa bounding language that is defined according to a second structuredmarkup language definition document that specifies allowablerestrictions on how contents of the structured document can bemanipulated, wherein the structured document is defined according to afirst structured markup language definition document; and charging a feefor carrying out the providing step.
 26. The method according to claim25, further comprising the step of using the provided bounding file toenforce the determined restrictions on how the structured document canbe manipulated.
 27. The method according to claim 25, further comprisingthe step of providing an editing capability that enforces the determinedrestrictions on how the structured document can be manipulated.
 28. Abounding document encoded in a structured markup language, wherein thebounding document is stored on one or more computer-readable media andcomprises: one or more rules on how a structured document can be edited,wherein: the one or more rules are encoded in the structured markuplanguage, and adhere to a bounding language that is defined according toa bounding language definition document that specifies allowable ruleson how contents of the structured document can be manipulated; and thestructured document is defined according to a structured markup languagedefinition document.
 29. The bounding document according to claim 28,wherein the one or more rules refer to markup language elements definedin the structured markup language definition document.
 30. The boundingdocument according to claim 28, wherein the one or more rules arerestrictions on how the structured document can be edited.